Heterogeneous database environments are environments that contain different, and often incompatible, types of database systems. These different database systems are typically purchased independently by businesses to serve a particular need, function or use of the data. As a result, businesses may have information spread across multiple database management systems. Since every database management system vendor attempts to provide a competitive edge over the offerings of its competitors, the different database management systems are almost by definition incompatible. Even database systems based on SQL language standards and the relational model will be incompatible due to differences in SQL implementations, database definition and communication mechanisms. Incompatibility problems are even more apparent between modem relational database management systems and legacy database management systems that use a hierarchical or network architecture. Hence, the task of combining incompatible database systems is extremely complex.
One prior method for integrating foreign databases or data storage in a heterogeneous environment is depicted in FIG. 1A. FIG. 1A is a diagram of a heterogeneous environment having a database application 10 configured to communicate with foreign databases 12 and 14. The database application 10 from one vendor communicates with the foreign database systems 12 and 14 of other vendors using hardcoded instructions 16 and 18 for the foreign databases 12 and 14, respectively. However, this arrangement is limited from an extensibility and scalability point of view, since every application in the heterogeneous environment must be rebuilt with new hardcoded instructions every time an unfamiliar foreign database is added to the heterogeneous environment. Hence, the application 10 would not be able to access a foreign database if the particular instructions for the data format and definitions of that foreign database were not coded directly into the application 10.
Another prior method is shown in FIG. 1B, where a database system 20 accesses the foreign databases 12 and 14 via a gateway 22. The gateway 22 allows client applications to access the foreign databases by translating data and SQL statements having the format of the database system 20 into formats that are recognizable by the foreign database systems. Specifically, the gateway 22 maps the data representation and functionality of one data source onto another data source, performing a translation of SQL statements from the database system 20 into a syntax recognizable by either the foreign database 12 or the foreign database 14. The gateway 22 then sends the translated commands to the targeted foreign database, maps the resulting data from the targeted database into the format of the database system 20, and sends the resultant data back to the database system 20.
Use of the gateway 22, however, suffers from the disadvantage that the mapping mechanisms in the gateway 22 tend to support only the most basic functionality that is common to all of the various databases. Hence, the functionality level of the mapping mechanism is effectively lowered to the lowest common denominator within the group of databases supported by the gateway 22. In addition, SQL mapping by the gateway 22 cannot be performed dynamically, requiring the mapping definitions to be regenerated each time a new and unrecognized foreign database is added. Finally, database performance may be effected since the gateway 22 adds another layer of complexity between the application and the foreign databases.